Перейти к основному содержимому

4.12. Мобильные приложения

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Архитектору Инженеру

Мобильные приложения​

Смартфон — это полноценная вычислительная платформа, умещающаяся в кармане. Его аппаратная база включает многоядерный процессор, графический ускоритель, модули связи (Wi‑Fi, Bluetooth, сотовые сети), датчики (акселерометр, гироскоп, барометр, освещённости), радиочастотные компоненты (NFC, GPS), а также высокоёмкую перезаряжаемую батарею. Однако аппаратное оснащение само по себе не создаёт функциональности — именно мобильная операционная система обеспечивает управление ресурсами, запуск программ и взаимодействие с пользователем. А программная функциональность, ориентированная на конечного пользователя, реализуется через мобильные приложения.

Мобильное приложение — это программное средство, разрабатываемое и распространяемое специально для установки и выполнения на мобильных устройствах: смартфонах и планшетах. Оно предназначено для работы под управлением мобильной операционной системы (в настоящее время доминируют iOS и Android), оптимизировано под ограниченные ресурсы устройства (экран, вычислительная мощность, энергопотребление), а также под специфику пользовательского взаимодействия — в первую очередь, сенсорного ввода.

Важно провести чёткое различие между устройством, операционной системой, мобильной платформой и приложением, поскольку эти понятия часто смешиваются в неспециализированной речи.

  • Смартфон — персональное мобильное устройство с сенсорным дисплеем (от 4,5 до 6,8 дюймов по диагонали), работающее под управлением мобильной ОС. Его ключевая роль — обеспечивать мобильность, постоянную связь и доступ к сервисам в любое время и в любом месте. Термин «телефон» в данном контексте уже не отражает сущности устройства: даже устройства без сотового модуля (например, iPad Wi‑Fi) могут выполнять большинство функций, характерных для смартфонов, и запускать те же приложения.

  • Планшет — устройство с увеличенным сенсорным экраном (типично 7–13 дюймов), также использующее мобильную ОС (Android или iPadOS). Архитектурно и программно планшет максимально совместим со смартфоном, но предъявляет иные требования к адаптивности интерфейса: приложение должно корректно масштабироваться, поддерживать многоколоночные макеты, учитывать различия в плотности пикселей и в поведении окон. iPadOS, например, вводит концепции многозадачности (Slide Over, Split View), которые требуют от разработчика дополнительной проработки пользовательского опыта — и это уже выходит за пределы простого масштабирования.

  • Мобильная операционная система — программная среда, обеспечивающая управление аппаратными ресурсами, безопасность, запуск и изоляцию приложений, а также предоставление стандартных API для доступа к функциональности устройства. Ключевое отличие мобильной ОС от настольной заключается в строгом контроле жизненного цикла приложения: система может приостановить, свернуть или завершить приложение в любой момент для освобождения ресурсов. iOS и Android реализуют это по-разному, но обе исходят из одного принципа: приложение не владеет устройством — оно лишь временно использует его ресурсы по разрешению системы.

  • Мобильное приложение — программный продукт, созданный для установки и работы на указанной платформе. Оно может быть полностью автономным, частично зависеть от сетевых сервисов или представлять собой клиент распределённой системы. Архитектурно мобильное приложение включает графический интерфейс пользователя, логику обработки данных, механизмы взаимодействия с системными сервисами (камера, геолокация, уведомления), а также интеграцию с внешними API. Его жизненный цикл управляется операционной системой: запуск, активация, фоновая работа, приостановка, завершение — все эти состояния должны быть явно обработаны разработчиком.

Мобильная разработка​

Мобильная разработка — это дисциплина, объединяющая проектирование, реализацию, тестирование и сопровождение программного обеспечения, ориентированного на мобильные устройства. Она не сводится лишь к написанию кода на Swift или Kotlin; это целостный процесс, включающий работу с ограничениями и возможностями уникальной среды выполнения.

Основное отличие мобильной разработки от веб- и десктоп-разработки лежит в модели взаимодействия пользователя, устройства и системы.

В десктопной разработке приложение, как правило, запускается в полноэкранном или оконном режиме, имеет стабильный доступ к ресурсам (памяти, процессору, хранилищу), управление жизненным циклом осуществляется пользователем («закрыл окно — приложение завершилось»), а входные данные поступают преимущественно через клавиатуру и мышь. В веб-разработке — даже с учётом адаптивного дизайна — основной акцент делается на кроссбраузерность, сетевую задержку, архитектурное разделение клиент/сервер, и приложение не имеет прямого доступа к аппаратным возможностям устройства (кроме ограниченных Web API, например, Geolocation или Camera).

Мобильная же разработка требует:

  • Учёт энергопотребления как критерия качества. Приложение, активно использующее CPU, геолокацию или Bluetooth в фоне, напрямую влияет на срок автономной работы устройства. Системы iOS и Android вводят энергетические бюджеты и ограничения на фоновую активность — например, фоновая выборка данных в iOS ограничена по частоте и продолжительности, а в Android с версии 8.0 введены ограничения на фоновые сервисы. Разработчик обязан проектировать архитектуру с учётом этих лимитов: использовать отложенные задачи (deferred work), оптимизировать сетевые запросы (batching, coalescing), минимизировать wake-locks.

  • Поддержка асинхронного и прерываемого жизненного цикла. Мобильное приложение не «работает», пока пользователь с ним взаимодействует — оно периодически переходит в фон, приостанавливается, сохраняет состояние, восстанавливается. Это требует явной реализации механизмов сохранения контекста: корректного восстановления UI-состояния с учётом возможных изменений (например, поворот экрана, смена темы, обновление данных в фоне).

  • Адаптация к разнообразию экранов и форм-факторов. Даже в рамках одной экосистемы (например, Android) существуют тысячи моделей устройств с различными соотношениями сторон, плотностью пикселей, размерами экранов. iOS формально ограничена несколькими размерами, но с появлением Dynamic Type, Dark Mode, Scene-based режимов многозадачности и поддержки внешних дисплеев (на iPad) задача адаптации остаётся нетривиальной. От разработчика требуется использование адаптивных макетов: Auto Layout и Size Classes в iOS, ConstraintLayout и Jetpack WindowManager в Android.

  • Работа с разрешениями и приватностью. Доступ к чувствительным данным (местоположение, контакты, камера, микрофон) регулируется на уровне ОС и на уровне магазина приложений. Apple и Google обязывают разработчиков декларировать цели использования каждого разрешения (purpose strings), предоставлять чёткие обоснования в процессе модерации, а также реализовывать runtime-запросы с пояснениями. Приложение, запрашивающее доступ к геолокации «просто так», будет отклонено при публикации.

  • Интеграция с системными сервисами и другими приложениями. Мобильные ОС поощряют композицию: приложение может делиться контентом через системный Share Sheet, получать изображения из Photos, открывать ссылки в Safari/Chrome Custom Tabs, использовать биометрическую аутентификацию через системный фреймворк. Это снижает необходимость в собственных реализациях и повышает безопасность, но требует глубокого понимания принципов inter-app communication (URL schemes, Intents, App Extensions, Content Providers).

Эти особенности делают мобильную разработку самостоятельной инженерной дисциплиной, требующей специфических компетенций в области архитектуры, UX, энергоэффективности и безопасности.

Классификация мобильных приложений​

Мобильные приложения можно классифицировать по нескольким независимым признакам. Ни одна из классификаций не является исчерпывающей, но совокупность критериев позволяет точно описать тип приложения и его технические требования.

По архитектуре и способу реализации​

Существует три основных подхода к созданию мобильных приложений, различающихся степенью зависимости от нативных возможностей платформы.

Нативная разработка подразумевает создание отдельных кодовых баз для каждой целевой операционной системы с использованием официальных языков, инструментов и фреймворков. Для iOS это Swift (и частично Objective‑C) в среде Xcode с использованием UIKit или SwiftUI; для Android — Kotlin (и частично Java) в Android Studio с Jetpack Compose или классической XML-разметкой. Преимущества: максимальная производительность, полный доступ ко всем API, своевременная поддержка новых функций платформы, соответствие гайдлайнам Human Interface Guidelines (iOS) и Material Design (Android). Недостатки: удвоение усилий при поддержке двух платформ, необходимость владения двумя технологическими стеками.

Кроссплатформенная разработка предполагает написание единой логической и UI-части, которая транслируется или интерпретируется на обеих платформах. Существует несколько стратегий:

  • Компиляция в нативный код (Flutter): фреймворк предоставляет собственную графическую подсистему (Skia), а код на Dart компилируется в машинный код для ARM/x64. UI-компоненты не являются «обёртками» над нативными — они рисуются напрямую, что обеспечивает высокую согласованность поведения и производительность, близкую к нативной.
  • Вызов нативных компонентов через мост (React Native): JavaScript-код управляет логикой, а компоненты UI отображаются через нативные представления (UIView в iOS, View в Android). Это позволяет сохранить внешний вид, соответствующий платформе, но вводит накладные расходы на сериализацию сообщений между JS и нативным слоем.
  • Общий бизнес-код + нативный UI (Kotlin Multiplatform Mobile): логика (модели, репозитории, use cases) пишется один раз на Kotlin и компилируется в нативные библиотеки (framework для iOS, JVM-библиотеку для Android), а интерфейс реализуется стандартными средствами каждой платформы. Это гибридный подход, ориентированный на максимальное переиспользование без ущерба для UX.

Гибридная разработка использует веб-технологии (HTML, CSS, JavaScript) внутри нативного контейнера — WebView. Приложение представляет собой локально размещённое веб-приложение, упакованное в «обёртку» (например, через Apache Cordova, Ionic или Capacitor). Доступ к нативным API осуществляется через JavaScript-плагины. Такой подход экономичен для простых интерфейсов и команд с веб-экспертизой, но страдает от ограничений WebView: производительность анимаций, задержки ввода, отсутствие поддержки некоторых API, сложности с фоновой работой. Современные гибридные решения (Capacitor) значительно улучшили интеграцию, но всё равно не подходят для высоконагруженных сценариев — например, 3D-игр или обработки видео в реальном времени.

По режиму работы​

Приложения различаются по зависимости от сетевого подключения.

Оффлайн-приложения полностью функциональны без доступа к интернету: данные хранятся локально (в SQLite, Realm, Core Data, Room), интерфейс и логика не требуют внешних вызовов. Примеры: калькуляторы, оффлайн-карты (загруженные заранее), одиночные игры, редакторы текста. Ключевая задача — обеспечить целостность данных и корректную синхронизацию при последующем подключении (если она предусмотрена).

Онлайн-приложения предполагают постоянное или частое взаимодействие с сервером: социальные сети, мессенджеры, банковские клиенты, стриминговые сервисы. Здесь доминируют задачи управления сетевыми ошибками, кэширования, работы в условиях нестабильного соединения (например, перемещение в метро), а также безопасности передаваемых данных (HTTPS, certificate pinning, шифрование на уровне приложения).

Гибридные приложения сочетают оба режима: базовый функционал доступен оффлайн (например, просмотр сохранённых заметок), а расширенные возможности требуют сети (поиск в облаке, совместное редактирование). Архитектурно это требует чёткого разделения слоёв: repository pattern с несколькими источниками данных (local, remote), стратегий повторных попыток, очередей отложенных операций.

По целевому назначению​

Хотя границы зыбки, можно выделить несколько устойчивых категорий:

  • Утилиты — приложения, решающие одну конкретную задачу: фонарик, сканер QR-кодов, запись голоса.
  • Производственные и корпоративные — клиенты ERP, CRM, системы электронного документооборота. Часто используют enterprise-дистрибуцию (вне магазинов), MDM-политики, повышенные требования к безопасности.
  • Социальные и коммуникационные — мессенджеры, соцсети. Высокая нагрузка на сеть, push-уведомления, фоновая обработка сообщений, сквозное шифрование.
  • Мультимедийные — проигрыватели, редакторы фото/видео. Требуют оптимизации работы с графикой, использования аппаратного ускорения (MediaCodec, Core Video), управления памятью при работе с большими буферами.
  • Игровые — от простых казуальных до AAA-проектов. Подразумевают работу с 2D/3D-движками (Unity, Unreal, LibGDX), управление ресурсами (текстуры, аудио), монетизацию, аналитику, античит-механизмы. Отдельно рассматриваются мобильные игры — они обладают уникальной моделью распространения и экономикой.

Мобильные игры​

Мобильные игры составляют значительную долю загружаемого контента в магазинах приложений. Их разработка отличается бизнес-подходами.

Технически игры требуют:

  • Высокой частоты кадров (обычно 30 или 60 FPS) при минимальном энергопотреблении.
  • Эффективного управления памятью: загрузка ассетов по требованию (asset streaming), пулы объектов, освобождение ресурсов при переходе в фон.
  • Поддержки множества разрешений и соотношений сторон без искажений или обрезки игрового поля.
  • Интеграции с игровыми сервисами: сохранения в облаке (Game Center, Google Play Games), достижения, лидерборды.

Экономически подавляющее большинство мобильных игр распространяется по модели free-to-play (F2P) — условно-бесплатной. Приложение устанавливается бесплатно, но содержит механизмы монетизации внутри: покупки виртуальных товаров (валюты, скинов, ускорений), подписки на привилегии, рекламу.

Реклама в мобильных играх реализуется через специализированные SDK (AdMob, AppLovin, ironSource) и бывает нескольких типов:

  • Баннеры — статичные или анимированные полосы внизу или сверху экрана. Наименее навязчивы, но и наименее доходны.
  • Межстраничные (interstitial) — полноэкранные рекламные блоки, показываемые между уровнями или в естественных точках остановки. Более эффективны, но нарушают игровой поток.
  • Наградные видео (rewarded video) — пользователь добровольно смотрит рекламу в обмен на внутриигровое вознаграждение (дополнительная жизнь, валюта). Эта модель считается наиболее этичной и прибыльной, так как сочетает монетизацию с улучшением UX.

Важный аспект — баланс между монетизацией и удержанием. Чрезмерная реклама или агрессивные paywalls снижают Retention Rate (показатель удержания пользователей), что в долгосрочной перспективе уменьшает общую прибыль. Поэтому современные игры проектируются с учётом «экономики внимания»: игровые циклы (loop), временные ограничения (cooldowns), социальное взаимодействие (кланы, совместные события), всё это создаёт устойчивую мотивацию к возврату, что позволяет встраивать монетизацию ненавязчиво.

Языки и инструменты: хотя игры могут писаться на нативных стеках, подавляющее большинство использует кроссплатформенные движки. Unity (C#) доминирует в сегменте 2D и 3D casual-игр; Unreal Engine (C++, Blueprints) — для high-end проектов; Godot (GDScript, C#) набирает популярность в indie-среде. Все они генерируют нативные APK/IPA, интегрируются с рекламными SDK и поддерживают аналитику (Firebase, GameAnalytics).

Процесс разработки на iOS​

Разработка под iOS требует строгого соблюдения экосистемных требований Apple. Процесс можно разделить на этапы.

1. Подготовка инфраструктуры.
Для работы с iOS необходим компьютер на macOS (Intel или Apple Silicon), поскольку официальная среда разработки — Xcode — доступна только в App Store и не поддерживает других ОС. Установка Xcode включает в себя компиляторы (Clang, Swift), симуляторы устройств, инструменты профилирования (Instruments), а также SDK для всех актуальных версий iOS/iPadOS/watchOS/tvOS.

2. Создание Apple Developer Account.
Для подписи приложений и публикации в App Store требуется платная учётная запись разработчика (99 USD/год). В рамках неё регистрируются:

  • Certificates — цифровые сертификаты для подписи кода.
  • Identifiers — уникальные bundle ID приложений.
  • Devices — UDID устройств для тестирования (до 100 в год).
  • Profiles — provisioning profiles, связывающие сертификаты, идентификаторы и устройства.

3. Проектирование и реализация.
Современная разработка на iOS рекомендует использовать Swift — язык, разработанный Apple с акцентом на безопасность, производительность и выразительность. SwiftUI — декларативный фреймворк для построения UI, интегрированный с Combine для реактивного программирования. Для legacy-проектов применяется UIKit с imperative-подходом.

Архитектурные паттерны: MVVM (Model‑View‑ViewModel) с Combine или async/await, Coordinators для навигации, Repository для абстракции источников данных. Обязательно использование App Sandbox — механизм изоляции, ограничивающий доступ приложения к файловой системе и другим процессам.

4. Тестирование.
Проводится на симуляторах (быстро, но не отражает реального поведения железа) и на физических устройствах (точно, но требует UDID-регистрации). TestFlight позволяет приглашать внешних тестировщиков (до 10 000) без публикации в магазине.

5. Подготовка к публикации.
Создаётся запись приложения в App Store Connect: метаданные (название, описание, категории, ключевые слова), скриншоты (для каждого поддерживаемого размера экрана), видео-превью. Загружается собранный архив (IPA) через Xcode Organizer или Transporter.

6. Модерация.
Процесс строгий и непрозрачный: команда Apple проверяет соответствие App Store Review Guidelines. Типичные причины отклонения:

  • Использование private API.
  • Нарушение политик конфиденциальности (отсутствие объяснения использования location/camera).
  • Некорректная реализация покупок (обход In-App Purchase для цифровых товаров).
  • Копирование функционала системных приложений без добавленной ценности. Среднее время модерации — от 24 часов до 5 дней.

7. Публикация и поддержка.
После одобрения приложение становится доступно в App Store. Apple предоставляет аналитику (App Analytics), возможность A/B-тестирования метаданных (Custom Product Pages), а также инструменты для управления подписками и возвратами.

Официальная документация — developer.apple.com/documentation — содержит полные спецификации всех фреймворков, руководства по Human Interface Guidelines, технические заметки (Tech Notes) и case studies. Обновления публикуются синхронно с релизами новых версий iOS.

Процесс разработки на Android​

Android-разработка отличается большей открытостью и, как следствие, — большей фрагментацией. Процесс формально проще в входе, но сложнее в обеспечении совместимости.

1. Подготовка среды.
Android Studio — официальная IDE, основанная на IntelliJ IDEA. Работает на Windows, macOS, Linux. Включает эмуляторы AVD (Android Virtual Device), профилировщик (Profiler), инструменты сборки (Gradle), а также Layout Inspector и Database Inspector.

2. Выбор языка и архитектуры.
Google официально рекомендует Kotlin как основной язык: он более лаконичен, безопасен (null-safety), поддерживает корутины для асинхронности. Java всё ещё поддерживается, но новые API часто появляются первыми в Kotlin-формате.

Современный UI строится с помощью Jetpack Compose — декларативного инструментария, аналогичного SwiftUI. Для legacy-кода используется XML-разметка с View-иерархией и ConstraintLayout. Архитектурные компоненты Jetpack (ViewModel, LiveData, Room, Navigation) стандартизируют построение приложений.

3. Управление зависимостями и сборкой.
Сборка управляется через Gradle. Для кроссплатформенных модулей (например, KMM) используются отдельные конфигурации. Важно правильно настроить build variants (debug/release), signingConfig, а также minSdkVersion и targetSdkVersion — последние напрямую влияют на доступность API и прохождение модерации в Google Play.

4. Тестирование.
В отличие от iOS, тестирование на эмуляторе часто бывает достаточным для ранних этапов, так как Android Emulator поддерживает аппаратное ускорение (Intel HAXM, Apple Hypervisor Framework). Тем не менее, тестирование на реальных устройствах критично из-за фрагментации: различия в OEM-оболочках (MIUI, One UI), в версиях Android, в наличии/отсутствии датчиков.

Инструменты: Espresso (UI-тесты), JUnit (unit), Robolectric (локальные Android-тесты), Firebase Test Lab (облачное тестирование на сотнях конфигураций).

5. Публикация в Google Play.
Требуется аккаунт разработчика (единоразовый платёж 25 USD). Процесс публикации проходит через Google Play Console. Начиная с 2021 года, введена обязательная регистрация в Play App Signing, где Google хранит ключ подписи, а разработчик загружает только upload key — это защищает от потери ключа.

Модерация в Google Play менее строга, чем в App Store, но имеет чёткие политики:

  • Запрещены приложения-клонеры без уникального контента.
  • Требуется явное согласие на сбор персональных данных (в соответствии с законодательством: GDPR, CCPA).
  • С 1 ноября 2025 года все новые приложения и обновления должны поддерживать страничную память 16 КБ (page size alignment), что актуально для устройств на ARM64 с увеличенным размером страницы — это требование повышает производительность на новых SoC.

6. Дополнительные инструменты.

  • Android Vitals — мониторинг стабильности, производительности, энергопотребления.
  • Pre-Launch Report — автоматическое тестирование на эмуляторах и реальных устройствах с отчётами об ошибках.
  • Internal Testing / Closed Testing / Open Testing — многоуровневая система бета-тестирования.

Официальная документация на русском языке доступна по адресу developer.android.com/?hl=ru. Там же — гайды по Material Design 3, Jetpack, безопасность, производительность, а также информация о режиме агента Gemini в Android Studio Narwhal Feature Drop: AI-ассистент, способный генерировать многофайловые решения по описанию на естественном языке.

Монетизация мобильных приложений​

Монетизация — неотъемлемая часть жизненного цикла большинства коммерческих мобильных приложений. Однако в отличие от десктопных или веб-решений, в мобильных экосистемах процесс получения прибыли от пользователя строго регулируется условиями магазинов приложений: App Store и Google Play. Это создаёт единый, но жёстко формализованный набор моделей, с которыми разработчик вынужден работать.

Наиболее распространённые модели:

Платные приложения​

Пользователь оплачивает установку единоразово. Технически это реализуется через механизм purchase flow магазина: при первом запуске приложение проверяет наличие лицензии, и при её отсутствии перенаправляет пользователя в магазин. Преимущества — отсутствие внутренней инфраструктуры монетизации, полная прозрачность для пользователя. Недостатки — высокий барьер входа, низкий коэффициент конверсии, невозможность повторного монетизационного контакта после оплаты.

На iOS и Android платные приложения должны распространяться исключительно через официальные магазины. Попытка обойти их — например, через direct APK-загрузку с сайта и оплату картой — нарушает условия использования и делает невозможным использование системных API (например, Push-уведомлений на iOS без подписи App Store).

Внутриприложные покупки (In-App Purchases, IAP)​

Это основная модель коммерциализации условно-бесплатных продуктов. Она поддерживается на уровне ОС: StoreKit (iOS) и Google Play Billing Library (Android). Архитектурно IAP бывает двух типов:

  • Потребляемые (consumable) — товары, которые можно приобрести многократно и которые «исчерпываются» при использовании (например, внутриигровая валюта, боеприпасы). После покупки приложение обязано подтвердить получение и применение товара, иначе система может вернуть средства пользователю.
  • Непотребляемые (non-consumable) — разовые покупки, не исчезающие со временем (разблокировка функций, пожизненная подписка). Они ассоциируются с учётной записью пользователя и могут быть восстановлены на других устройствах.
  • Подписки (subscriptions) — периодические платежи (еженедельно, ежемесячно, ежегодно). Поддержка включает автоматическое продление, grace period (период льготы при сбое оплаты), offer codes (скидки для новых/старых пользователей), family sharing (iOS), а также возможность предоставлять бесплатные пробные периоды.

Любой цифровой контент или функция, доступ к которой предоставляется внутри приложения, должен продаваться через IAP. Это включает в себя игры и SaaS-сервисы — например, подписка на облачный редактор. Обход через веб-оплату («купить на сайте — ввести код в приложении») запрещён Apple и влечёт отклонение приложения. Google допускает обход только для физических товаров и услуг вне приложения (например, доставка еды), но и здесь требуется строгое документальное обоснование.

Интеграция рекламы​

Реклама — альтернативный или дополнительный источник дохода, особенно актуальный для высокоустановливаемых приложений. Техническая реализация сводится к интеграции SDK от рекламных сетей (AdMob, Meta Audience Network, AppLovin MAX и др.). Однако архитектурно это требует:

  • Медиации (mediation) — промежуточного слоя, выбирающего, какая рекламная сеть покажет объявление в данный момент, исходя из eCPM (эффективной стоимости за тысячу показов). Без медиации прибыль снижается на 20–40 %.
  • Контроля качества — фильтрации low-quality creatives (мошеннические баннеры, вирусные ссылки), что особенно важно для детских и корпоративных приложений.
  • Соблюдения политик приватности — с 2023 года Apple требует явного согласия на tracking через AppTrackingTransparency (ATT), Google реализует аналогичные механизмы в рамках Privacy Sandbox. Приложение, не реализующее запрос разрешения, не может использовать идентификатор рекламы (IDFA на iOS, AAID на Android), что радикально снижает таргетинг и доход.

Особый класс — наградная реклама (rewarded ads). Здесь пользователь добровольно соглашается посмотреть видео или пройти интерактивное объявление в обмен на внутриигровое вознаграждение. Архитектурно это требует:

  • Предварительной загрузки рекламного контента (preload), чтобы избежать задержек.
  • Проверки валидности награды на стороне сервера (server-side verification), иначе возможны читы через модификацию клиентского кода.
  • Чёткого разделения между «просмотрено» и «засчитано» — пользователь может закрыть рекламу до завершения, и вознаграждение не должно начисляться.

Система разрешений​

Доступ к аппаратным и программным возможностям устройства регулируется через систему разрешений (permissions). Однако реализация на iOS и Android принципиально различается.

Android​

Начиная с Android 6.0 (API level 23), большинство чувствительных разрешений (location, camera, contacts и др.) запрашиваются во время выполнения, а не при установке. Разработчик обязан:

  • Декларировать разрешение в AndroidManifest.xml.
  • Проверять наличие разрешения перед вызовом API.
  • При отсутствии — инициировать запрос через ActivityCompat.requestPermissions().
  • Обрабатывать результат в onRequestPermissionsResult().

С версии Android 10 введены точные и приблизительные разрешения на геолокацию (ACCESS_FINE_LOCATION и ACCESS_COARSE_LOCATION), а с Android 11 — одноразовые разрешения (one-time permissions): пользователь может разрешить доступ «только на этот раз», после чего при следующем запросе система снова покажет диалог.

Критически важно: если приложение запрашивает разрешение, но не объясняет его необходимость, пользователь, скорее всего, откажет. Поэтому Google рекомендует использовать rationale UI — краткое пояснение до системного диалога (например: «Для поиска ближайших кафе нам нужен доступ к местоположению»).

iOS​

В iOS разрешения также запрашиваются во время выполнения, но ключевой акцент сделан на прозрачности использования данных. Разработчик обязан:

  • Добавить в Info.plist соответствующую purpose string (например, NSLocationWhenInUseUsageDescription) с объяснением на естественном языке.
  • Запросить разрешение через соответствующий фреймворк (CLLocationManager.requestWhenInUseAuthorization() и др.).
  • Обрабатывать результат в делегате.

С 2023 года Apple ввела Privacy Manifests — XML-файлы, в которых сторонние библиотеки (включая рекламные SDK) обязаны декларировать все собираемые данные и цели их использования. Приложение, использующее библиотеку без Privacy Manifest или с нарушениями, будет отклонено при модерации.

Важное различие: в iOS отсутствует концепция «одноразового разрешения», но есть градации доступа — например, для геолокации: «Только при использовании приложения», «Разрешить всегда», «Спросить в следующий раз». С iOS 14 добавлена опция Precise Location: пользователь может разрешить доступ к точным координатам или только к приблизительным (с точностью до района города).

Общее правило для обеих платформ: запрашивайте разрешение только в момент, когда оно действительно необходимо для выполнения действия, инициированного пользователем. Запрос при старте приложения снижает конверсию разрешений на 30–60 %.

Ограничения платформ​

Мобильные экосистемы накладывают технические и поведенческие ограничения на приложения. Эти ограничения не являются произвольными — они следуют из целей платформ: стабильность, безопасность, энергоэффективность, единообразие UX.

iOS​

  • App Sandbox — каждое приложение работает в изолированном контейнере. Доступ к файлам других приложений запрещён. Обмен данными возможен только через системные механизмы: Shared Keychain (ограниченно), App Groups (для собственных приложений одного разработчика), Universal Links, UIActivityViewController.

  • Фоновые ограничения — приложение в фоне имеет не более 30 секунд (iOS 13+) для завершения критических задач. Длительная фоновая активность разрешена только для строго определённых типов: аудио/видео-воспроизведение, геолокация в навигации, VoIP, Bluetooth LE-взаимодействие, фоновая выборка (fetch) — но последняя ограничена до 1–2 раз в час и зависит от энергетического профиля устройства.

  • Запрет на динамическую загрузку кода — JIT-компиляция и загрузка исполняемого кода из сети (кроме WebAssembly в WKWebView) запрещены. Это исключает использование некоторых кроссплатформенных решений без предварительной компиляции.

Android​

  • Более широкие возможности фоновой работы, но с постепенным ужесточением: с Android 8.0 ограничены фоновые сервисы, с Android 9 — ограничения на использование переднего плана (foreground service notifications обязательны), с Android 12 — новые разрешения для точного местоположения и Bluetooth scanning.

  • Поддержка альтернативных магазинов и direct install — APK может быть установлен из любого источника при включённой опции «Неизвестные источники». Однако Google Play Protect сканирует такие приложения на угрозы, а многие OEM (например, Samsung) добавляют собственные предупреждения.

  • С 1 ноября 2025 года — обязательная поддержка 16 КБ страниц памяти (page size alignment). Это требование связано с переходом на новые SoC (например, Snapdragon 8 Gen 4 и выше), где базовый размер страницы памяти увеличен с 4 КБ до 16 КБ. Приложения, не выровненные по границам 16 КБ (например, native-библиотеки, скомпилированные без флага -Wl,-z,max-page-size=0x4000), могут работать нестабильно или не запускаться вовсе. Google рекомендует проверять совместимость через Play Console → Testing → Pre-launch report.

Сравнение экосистем​

АспектApp Store (iOS)Google Play (Android)
Стоимость аккаунта99 USD/год25 USD (единоразово)
МодерацияРучная, строгая, непрозрачная; 1–5 днейАвтоматизированная + выборочная ручная; обычно < 24 ч
ОтклоненияЧасты по причинам UX, privacy, копирования функцийЧасты по причинам вредоносного поведения, обмана, нарушения политик монетизации
География распространенияОдин аккаунт — все регионы; цены устанавливаются по регионамВозможность ограничения по странам, staged rollouts (постепенный релиз)
Enterprise-дистрибуцияТребует Enterprise Developer Program (299 USD/год), UDID-регистрация невозможнаВозможна через внутренние магазины (например, Samsung Knox, VMware Workspace ONE), private apps в Play Console (без публикации)
Монетизация15 % для малого бизнеса (< 1 млн USD/год), иначе 30 %15 % для первых 1 млн USD, затем 30 %; с 2024 — снижено до 15 % для подписок после первого года
АналитикаApp Analytics (встроена, но ограничена)Google Play Console + Firebase (глубокая интеграция)

Общая тенденция: Apple стремится к контролируемой экосистеме, где качество и безопасность приоритетны над свободой; Google — к открытой, но регулируемой среде, где гибкость компенсируется автоматизированным контролем. Для разработчика это означает: на iOS выше порог входа, но ниже риски фрагментации; на Android — быстрый старт, но необходимость тестирования на десятках конфигураций.